HL7 FHIR
FHIR (Fast Healthcare Interoperability Resources) is an HL7 standard for exchanging healthcare data. It combines a modular data model with a plain RESTful API, which is why it has become the default choice for new health data integrations.
The core ideas
1. Resources
Everything is a resource — a self-contained unit of clinical or administrative meaning with a stable identity:
| Resource | Represents |
|---|---|
Patient | A person receiving care |
Practitioner | A person providing care |
Organization | A facility, department or agency |
Encounter | An interaction between patient and provider |
Observation | A measurement or finding |
Condition | A diagnosis or problem |
Immunization | A vaccine administration |
MedicationRequest | A prescription |
Around 150 resource types cover clinical, workflow, financial and conformance concerns.
2. A REST API
Resources are addressable over HTTPS with ordinary verbs:
GET /Patient/12345
GET /Observation?patient=12345&code=http://loinc.org|8867-4
POST /Encounter
PUT /Patient/12345
Responses are JSON (or XML). Any team with an HTTP client can integrate — no proprietary toolkit required.
3. References
Resources link to each other rather than nesting everything:
{
"resourceType": "Observation",
"subject": { "reference": "Patient/12345" },
"encounter": { "reference": "Encounter/98765" }
}
4. Extensions
The 80/20 rule: the base resource covers what most implementations need, and anything else is added as a named extension rather than by bending existing fields.
5. Conformance
Servers publish a CapabilityStatement describing what they support.
Implementers constrain resources with profiles and package them as
implementation guides, so validation is machine-checkable instead of
prose-checkable.
Terminology binding
FHIR carries codes rather than free text. Codings normally come from published systems:
- ICD — classification for reporting and billing
- SNOMED CT — clinical terminology
- LOINC — laboratory tests and observations
A CodeableConcept can carry several codings plus human-readable text, which is
what makes cross-system mapping tractable.
Exchange paradigms
FHIR supports more than one integration style:
- REST — request/response against a FHIR server.
- Documents — a
Bundlefixed at a point in time (e.g. a discharge summary). - Messages — event-driven exchange, familiar from HL7 v2.
- Operations — named RPC-style calls such as
$everythingor$validate. - Subscriptions — notifications when matching data changes.
Versions
FHIR has moved through DSTU1, DSTU2, STU3, R4, R4B and R5, with normative status growing release by release. R4 is the most widely deployed base today. Later releases refine resources, tighten terminology bindings and change some search behaviour — which is why upgrades are planned as migrations with parallel environments rather than as in-place switches.
Where it fits
| Job | Standard |
|---|---|
| Exchange between systems | FHIR |
| Legacy hospital messaging | HL7 v2 |
| National exchange architecture | OpenHIE |
| Analytics at population scale | OMOP |
Implementations
- HAPI FHIR — reference Java implementation
- FHIR servers — the wider server landscape
- Integration engines — for systems that cannot speak FHIR directly
Practical cautions
- Conformance is not interoperability. Two conformant servers can still disagree on identifiers, terminology and workflow.
- Identifiers first. See FHIR identifiers for why patient matching decides whether an integration works.
- Version pinning matters. Clients should state which FHIR release they target.
References
- HL7 FHIR specification — https://hl7.org/fhir/
- FHIR Implementation Guide registry — https://fhir.org/guides/registry/
- Amakomaya's FHIR platform, including the FHIR v6 upgrade